In the field of embedded control systems, a software conventionally controls the system so that an event (a change in an input signal received from outside a system or a change) occurring in the system triggers an action associated with the event, and the action causes a consequence such as transition of a state of the system or a process being executed in a state.
A software developer prepares correspondence information that specifies allocation of an action to a pair of the state of the system and the event as specifications for the system. The correspondence information is expressed in a tabular form as a state transition table or in a diagrammatic form as a state transition diagram.
Based on the correspondence information, the developer writes a program, which implements the system by, for example, a source code written in programming language such as C language or the like. In recent years, a program generation system that, upon receipt of an input of a state transition table or a state transition diagram, automatically translates the contents of the state transition table or diagram into the source code in the programming language has been developed (refer to, for example, Japanese Patent Document JP-A-2003-76543).
An example of conventional program generation based on the correspondence information is described with reference to FIG. 1 to FIG. 3. FIG. 1 shows an example of a state transition table that has been employed. In the table, each row specifies one event and each column specifies one state. That is, a transition from a state 1 to a state 2 and an action of performing process A are allocated to a pair of the state 1 and an event E1.
In the state transition table, a state has a hierarchical structure permitting one state to include child states. For example, the state 2 includes states 2-1 and 2-2 in FIG. 1. A state marked with an inverted triangle 41 or 42 is a state to which a transition will be made first on a hierarchical level to which the state belongs.
FIG. 2 shows an example of a state transition diagram that has been employed. In the diagram, a state is expressed with a rectangle having rounded corners. A transition from one state to another is expressed with an arrow. Characters appended to the arrow signify both an event that brings about a state transition expressed with the arrow, and the process to be performed when the event takes place.
That is, an arrow from a rectangle of a certain state and characters appended thereto specifies the state and the event expected to occur in the state. The arrow with the appended characters also specifies an action allocated to the pair of the state and the event.
Further, rectangles expressing child states subordinate to a certain state are drawn in a rectangle expressing the state in the state transition diagram. A state in the rectangle having an arrow starting with a black circle is the state to which a transition from another state is made first on a hierarchical level of the states.
The behavior of a system specified in the state transition table shown in FIG. 1 is identical to the behavior of a system specified in the state transition diagram shown in FIG. 2. That is, the table and diagram specify four actions described below.
(1) When an event E1 occurs in a state 1, process A is executed and a transition is made to a state 2-1.
(2) When the event E1 occurs in the state 2-1, a transition is made to a state 2-2.
(3) When the event E1 occurs in the state 2-2, process B is executed and a transition is made to the state 2-1.
(4) When an event E2 occurs in the state 2-2, processing C is executed and a transition is made to the state 1.0
FIG. 3 is a list of instructions included in a source code of C language generated by a conventional program generation system using the correspondence information shown in FIGS. 1 and 2. The C source code is described so that any of the foregoing actions (1) to (4) is performed depending on a pair of a state and an event specified by a GetState function, which represents reading of a current system state from the storage medium, and a GetEvent function, which represents reading of an event that currently takes place from the storage medium, respectively.
However, the conventional program generation system only defines conceivable states of the target system and associated actions in the specifications. That is, an action associated with a state that is not expected in a design stage of the system is described in neither of the specifications nor a generated program.
Therefore, a program generated by the conventional program generation system creates unsteady state of the system that the behavior of the system becomes totally unpredictable in a case where data supplied to the program for representing the state of the system changes to an unpredictable value for some reason. The unsteadiness of the system makes it impossible for the program to be used in an automotive system or the like that highly appreciates steadiness and consistency.